[レポート] Amazon EC2 スポットインスタンスの各社の利用例についてご紹介 #AmazonGameTech #AmznGameTechJP

Amazon Game Tech

#ソリューション

#初心者向け

#イベント

#勉強会

#ゲーム開発・運用

yoshihitoh

2019.11.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon EC2 スポットインスタンスの各社の利用例についてご紹介

2019年11月20日（水）にアマゾン目黒オフィスでアマゾンウェブサービス社の自社イベント「Amazon Game Developers Conference」が開催されました。

Amazon Game Developers Conference

本記事は、セッション「Amazon EC2 スポットインスタンスの各社の利用例についてご紹介」をレポートします。

スピーカー

株式会社アカツキサーバーサイドエンジニア駒井祐人さん
株式会社ドリコム執行役員インフラストラクチャー・基盤技術担当インフラストラクチャー部部長, 基盤技術部部長岡田達典さん
株式会社ディー・エヌ・エーシステム本部 IT基盤部第四グループ天野知樹さん
アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト保里善太さん

セッション概要

セッション紹介ページからの引用です。

Amazon EC2 スポットインスタンスは、AWS クラウドで使用可能な空きキャパシティをオンデマンドインスタンスに比べて大幅な割引価格で提供する購入オプションです。2017年11月にスポットインスタンスの価格安定化が実施され、様々な機能追加と合わせて大幅に使いやすくなりました。そんなスポットインスタンスは、ゲーム業界でも多く活用されています。本セッションでは、各ゲーム会社がどのようにスポットインスタンスを活用しているかを実用例を元に各社に解説していただきます。また、同時にスポットインスタンスの利点と実装する上での課題点、工夫した点を解説していただきます。

レポート

アジェンダ

はじめに
スポットインスタンスのおさらい
各社のスポットインスタンスの活用事例とアーキテクチャのご紹介
よくある課題に対してのQAディスカッション
まとめ

スポットインスタンスのおさらい

EC2の購入オプションは3種類
- オンデマンドインスタンス
- リザーブドインスタンス
- スポットインスタンス
  - オンデマンドインスタンスに対して最大で90%割引
EC2インスタンスの性能に差は無い
スポットインスタンスの特徴
- 価格は長期供給と需要に基づいて徐々に調整される
- AWSによって中断されることがある
- その場合は2分前までに通知される
スポットプールの分散
- 候補となるインスタンスタイプ・AZを複数選択することで中断に対するリスクを分散できる
Auto ScalingとEC2フリートの統合
- 単一ASGにオンデマンドインスタンス・リザーブドインスタンス・スポットインスタンスを組み合わせられる
耐障害製
スポットインスタンスの活用事例が色々でてる

各社のスポットインスタンスの活用事例とアーキテクチャのご紹介

アカツキ様の事例

ユニゾンエアーでスポットインスタンスを使ってる
- ライブ映像を使った音ゲー
ASGに複数のインスタンスタイプを組み合わせて使ってる
Lambdaを使ってASGをハンドリングしている
スポットインスタンスも同様
- 中断通知があった場合は、ALBから外して安全な状態で終了させる
- ASGで管理しているので、自動的にもとの台数に戻る

DeNA様の事例

ビッグタイトルでスポットインスタンスを活用している
ほとんどのサーバーがステートレスになっている
全体の半分ぐらいがスポットインスタンス
インスタンスファミリーごとにコア数あたりの処理性能が異なる
セカンダリIPを活用してサイズに応じた負荷分散を実現
使用できるタイプ数が増えたことによりプール数が増加し安定性向上
IP数単位でオートスケールを作成しスポットと統合

ドリコム様の事例

2015年ごろにはじめてスポットインスタンスを活用
以前はEC2フリートがなかった
インスタンスサイズごとにオンデマンド/スポットを組み合わせてASGを組む
管理が難しく安定稼働が難しい
以前はCIなど開発環境で活用していた
スポットフリートのおかげでだいぶ運用しやすくなった

よくある課題に対してのQAディスカッション

以降の回答は回答順に記載しています。

ぶっちゃけどんだけ安くなるの？

Q1) サービス全体で見た時にオンデマンドインスタンスに比べてどれだけ安くなっていますか？

アカツキ様) Spot価格だけで75%、システム全体だと60%節約。RIよりも安くなってる。価格の安定化以降は全然ブレなくて安心して使える
ドリコム様) 50%節約が目標値。新サービスで利用予定。徐々にスポットに寄せて調整することも考えている
DeNA様) 50%節約。 99%以上スポットにしてるコンポーネントもある。

スポット中断に対する耐久性

Q2) スポットインスタンスって本番環境で本当に使えるんですか？

DeNA様) まったく問題ない。同時にすべてが落ちない限りは影響なし。心の安全のためオンデマンドも1台だけ残してる。 (1台あれば復旧が用意になる)
ドリコム様) 昔は価格変動の問題もありリスクが高く使っていなかった。スポットフリートと価格の安定化に伴い今は安心して使えそう。
アカツキ様) まったく問題ない。時間帯によってスポットが落ちやすくなることもあるがすぐに次のインスタンスが上がってくる。本番環境でエラーなく動いている。 (HealthyHostcountの推移の図あり)

スポット中断に対する耐久性

Q3) どのようにスポット中断のリスクに対して耐久性を上げていますか？

ドリコム様) ライフサイクルイベントを活用して問題ないようにハンドリングしている。耐久性というよりは落ちることを前提に安全にシャットダウンをかける
DeNA様) 2分間の間に以下に安全にEC2を落とすようにしてる。EC2のメタデータを使ってハンドリングしている。(過去の経緯) 今やるならCloudWatch Eventが良い。DNS/ELBから抜いたりキューからデータを取りにいかないようにしたり。年末年始やクリスマス商戦・サイバーマンデーなど大規模なセールとかぶるとスポットインスタンスが落ちやすい。
アカツキ様) 中断通知を適切にハンドリングする。スポットプールで色んなインスタンスタイプとAZを分散させることで、特定インスタンスタイプが一斉に中断するときでもリスク回避できている。

中断時のハンドリングについて

Q4) 実際に中断が起こってしまった時にどのような処理を実行していますか？

→ 構成図で話したため割愛

Q5) 2分前中断通知時にどのようにログ等を回収していますか？

アカツキ様) fluentdを使って一定間隔でflushしている。プロセスが落ちるときもflushするように設定している。本当に重要なログは別の仕組みで保存している。
DeNA様) 独自で作り込んでいる。EBSにログを保存してスポットが落ちるときに削除しないようにする。あとでバッチ処理でアタッチして回収する。インスタンスが呼称したときでもログを回収できて良い。バッチが詰まると課金が高くなるので注意。
ドリコム様) アカツキ様と同様でfluentdベースで対応している。プロセスが落ちるときもflushするように設定している。

スポットの中断リスクに対する心構え

Q6) スポットインスタンスの中断リスクに対してエンジニアが常に神経を尖らせているのは精神衛生上良くないが、どのようにメンタルは対処していますか？

ドリコム様) スポットインスタンスに限らずサーバーは落ちるものと認識する。ポジティブにとらえてサービス全体のアベイラビリティを高めるようにする。
アカツキ様) 監視の基本は外形監視なので、スポットインスタンスの停止に一喜一憂しなくても良い。
DeNA様) (時間の問題でスキップ)

スポットインスタンスへの期待と要望

Q7) 改善して欲しい要望などございますか？

アカツキ様) ASGとスポットインスタンスを統合した場合、中断通知のテストができない。SpotFleetを個別に立て、リクエスト台数を減らすことでテストができるが、少し手間がかかるので改善してほしい。
ドリコム様) ドキュメントやサンプルを充実させてほしい
DeNA様) IPつけて制御したりの作り込みが大変。重み付きラウンドロビン的なものが欲しい。ということを話していたら昨日来た。ASGとの統合はどうだろう？